As an example of an apparatus which accepts a plurality of setup values input from the user via a user interface (to be also referred to as “UI” hereinafter), and is controlled based on these setup values, an image forming apparatus (printer apparatus) is known. In general, a printer apparatus comprises a printer driver for controlling a print process, and the printer driver includes a UI that accepts print setups and the like from the user.
Every time the printer driver accepts a setup value input from the user via the UI, it evaluates the relationship between the currently input setup value and an associated one of a plurality of setup values set so far, and checks if conflicts occur between the setup values. Examples of conflicts include a setup disadvantageous for the user (e.g., a setup of a two-sided print process for an OHP sheet set as a print medium), a setup that makes a printer execute impossible operations, and the like.
If any conflicts are found, a conflict process for eliminating such conflicts must be executed.
Conventionally, it is a common practice to use a dedicated conflict process program that discriminates conflicts and executes a conflict process depending on the relationship between setup values. Alternatively, a plurality of setup value conditions that require a conflict process are saved in the form of a list in, e.g., a file, which is loaded by a conflict process program, thus preventing the conflict process program from depending on a specific setup value, and allowing general-purpose use of that conflict process program.
However, in order to implement them, a program developer or the like must exhaustively describe all conflict process rules. For this reason, when dependency among setup values is complicated, not all conditions can be perfectly exhaustively described.
Conventionally, rules are described based on combinations, and only one-to-one objective function control is available. Upon adding a new rule, an input person must check the entire description. The input volume is very large since data must be generated to exhaustively cover all combinations. Also, since rules are described together, they contain repetitive descriptions and input errors with high possibility, and a huge number of correction steps are required.
In the conflict process program, a conflict manager that controls a conflict process is designed to have high maintainability independently from a main program so as to generally use conflict process rules. With this design, the conflict manager is seen as a black box from the main program.
However, in practice, the main program must update the UI, and an update process of the UI is required upon a change in specific setup value which does not influence the conflict process. Conventionally, in such case, the main program cannot selectively process corresponding items but must refresh a given range as a whole, resulting in poor processing efficiency of the main program.
Such update process may be determined based on a difference of a data structure as a mediation between the main program and conflict manager, but this method also suffers poor efficiency. In addition, when grayout and display/non-display of control are changed, it is hard to extract them, thus worsening efficiency.